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(57) ABSTRACT 

A method and apparatus is disclosed for approving a trans- 
action request between an electronic transaction system and 
a portable electronic authorization device (PEAD) carried by 
a user using an electronic service authorization token. The 
method includes the steps of receiving at the PEAD first 
digital data representing the transaction request. The PEAD 
provides information to the user regarding an ability to 
approve the transaction request. When the transaction 
request is approved by the user, the PEAD receives second 
digital data representing the electronic service authorization 
token. In one aspect of the invention, the method and 
apparatus include a remote agent server that provides a 
bridge between the electronic transaction system and the 
PEAD. In yet another aspect of the invention, the method 
and apparatus are used at a point of sale location. Advan- 
tages of the invention include the ability to securely and 
conveniently perform transactions with a portable device. 
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ELECTRONIC TRANSACTION SYSTEMS 
AND METHODS THEREFOR 

RELATED APPLICATIONS 

This application is a continuation in part of U.S. Ser. No. 5 
09/067,176 filed Apr. 27, 1998, which is a continuation of 
U.S. Ser. No. 08/759,555 filed Dec. 4, 1996 now U.S. Pat. 
No. 5,917,913 

BACKGROUND OF THE INVENTION 

The present invention relates to methods and apparatus 10 
for conducting electronic transactions. More particularly, the 
present invention relates to portable electronic authorization 
devices (PEADs) which advantageously and substantially 
eliminate the security risks associated with prior art tech- 
niques of approving transactions between a user and an 
electronic transaction system. 

Electronic transaction systems are known. An electronic 
transaction system typically permits a user to conduct des- 
ignated transactions electronically, which substantially 0Q 
improves efficiency and convenience to the user. Examples 
of electronic transactions include transactions conducted via 
computer networks, automated teller machines (ATM's), 
automated point-of-sale systems, automated library systems, 
and the like. Transactions conducted via computer networks 
may encompass a wide range of transactions, including 
exchanging information and data via a computer network 
popularly known as the Internet, e.g., to make a purchase 
from a vendor on the network. ATM's typically permit users 
to conduct financial transactions (such as withdrawals, ^ 
transfers, deposits, and the like) vis-a-vis a financial insti- 
tution in an electronic manner. Automated point-of-sale 
systems may be employed by merchants to permit users to 
purchase products or services using the users'" electronic 
account, and automated library systems may be employed to 
permit library users to check out and return library materials. 
Other examples of electronic transaction systems arc readily 
available in popular literature and are not enumerated herein 
for brevity sake. 

To enhance security to the user's account, electronic 4 q 
transaction systems typically request the user to provide 
identification data to authenticate himself as the user autho- 
rized to approve the proposed transaction or transactions. If 
the user fails to provide the requested identification data, the 
proposed transaction or transactions are not authorized and 45 
will not be processed. The identification data may be 
required with each transaction. By way of example, an 
automated point-of-sale system may require the user to 
approve a purchase transaction and will accept an approval 
message only if it is satisfied that the person approving the 50 
transaction has furnished adequate identifying data authen- 
ticating himself as the person authorized to perform the 
approval. Alternatively, the identification data may be 
entered by the user at the start of a session to authenticate 
himself and enable that user to subsequently perform any 55 
number of transactions without Her authentication. 

In the prior art, users are typically required to manually 
enter the identification data into the electronic transaction 
system for authentication. Typically, the entry of identifica- 
tion data involves typing in a password on a numeric keypad 60 
or on a keyboard. The identification data is then compared 
with data previously stored within the electronic transaction 
system, and authentication is satisfied when there is a match. 
As mentioned previously, the transaction or transactions 
proposed will not be allowed to proceed if there is no match. 65 

Although prior art electronic transaction systems provide 
some protection from unauthorized access and use of the 
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user's account, there are disadvantages. To illustrate certain 
disadvantages associated with prior art electronic transac- 
tion systems, reference may be made to FIG. 1 herein. FIG. 
I shows an automated teller machine (ATM) 100, represent- 
ing the requesting device of an electronic transaction system 
102. Electronic transaction system 102 may include, for 
example, a central database 104 which contains previously- 
stored identification data and account data of user 106. 

To initiate a typical transaction with ATM 100, user 106 
first inserts a data card 107, such as a bank card or a credit 
card, into a card reader 109. Data card 107 typically includes 
a magnetic stripe that contains the account number and other 
information related to the user, which may then be read by 
card reader 109. The data stored in data card 107 enables 
electronic transaction system 102 to ascertain which account 
in database 104 user 106 wishes to transact business. 

Via a keypad 108 on ATM 100, user 106 may then be able 
to enter his identification data, e.g., his personal identifica- 
tion number (PIN), to authenticate himself. If the entered 
identification data matches the identification data stored with 
the account in database 104 that is identified by data card 
107, the user is authenticated and granted access to his 
account. If there is no match, authentication fails. After 
authentication, user 106 may be able to, for example, 
employ a combination of keypad 108 and a screen 110 to 
withdraw cash from his account, which results in cash being 
dispensed from ATM 100 and the balance in his account 
within database 104 correspondingly reduced. 

Theoretically, the identification data entered into ATM 
100 should be secure. In reality, there are many potential 
security risks to the identification data in prior art authen- 
tication techniques. Since the identification data is not 
encrypted before being entered into ATM 100, the non- 
encrypted identification data is vulnerable to unauthorized 
access and procurement. Encryption of the identification 
data is not practical in the prior art since it would have been 
too complicated and/or inconvenient for the user to perform 
encryption or memorize the encrypted identification data. 
Unauthorized procurement of the identification data in the 
prior art may occur, for example, upon entry if it is inad- 
vertently seen by another party, e.g., by another person 
behind user 106, either on screen 110 or more likely at 
keypad 108. 

Even if encryption is employed on the identification data 
in the prior art, e.g., prior to transmission from ATM 100 to 
database 104, the encryption typically occurs within ATM 
100 and still requires the entry of non-encrypted identifica- 
tion data from user 106 and the existence of the identifica- 
tion data for some duration of time in ATM 100. Unautho- 
rized access to the identification data may then occur if an 
unauthorized party is able to gain entry into ATM 100 and 
intercepts, e.g., via software or hardware implemented in 
ATM 100, the non-encrypted identification data therein. 

Furthermore, if public key cryptography is employed 
within ATM 100, the storage of the user's private key within 
ATM 100 renders this private key vulnerable to theft, further 
exposing the user's account to risk. The stolen password 
and/or private key may then be employed to allow unau- 
thorized persons to access the user's account to the user's 
detriment. 

In view of the foregoing, there are desired apparatus and 
methods for conducting transactions with the electronic 
transaction system while substantially eliminate the risk of 
unauthorized access to the user's account and unauthorized 
procurement of the user identification data. Preferably, such 
an apparatus should be easily portable to permit the user to 
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conveniently and comfortably perform transaction authen- 
tication anywhere. 

SUMMARY OF THE INVENTION 

The present invention relates, in one embodiment, to a 5 
method for completing a transaction request pertaining to an 
electronic transaction conducted over an electronic network 
having a server and a requesting device. The method 
includes receiving from the server at the requesting device 
a transaction program, which includes an executable portion. 10 
The method also includes searching, employing the execut- 
able portion, for a transaction approval device associated 
with the requesting terminal. If the transaction approval 
device is detected, the method includes employing the 
transaction approval device to approve the transaction 15 
request. There is further included transmitting, using the 
requesting device, an approved transaction request to the 
server to complete the electronic transaction. The approved 
transaction request signifies an approval of the transaction 
request. 20 

In another embodiment, the invention relates to a method 
for completing a transaction request pertaining to an elec- 
tronic transaction conducted over an electronic network 
having a server and a requesting device. The method 
includes receiving from the server at the requesting device 25 
a transaction program, which includes an executable portion. 
The method also includes receiving from a user at the 
requesting device transaction approval data, wherein the 
executable portion of the transaction program includes a first 
set of codes configured to encrypt the transaction approval 30 
data. There is also included encrypting the transaction 
approval data using the first set of codes. There is further 
included transmitting, using transaction program, the 
encrypted transaction approval data to the server to complete 
the electronic transaction. 35 

In yet another embodiment, the invention relates to a 
method for completing a transaction request pertaining to an 
electronic transaction conducted over an electronic network 
having a server and a requesting device. The method 
includes receiving from the server at the requesting device 40 
a transaction program, which includes an executable portion. 
There is also included searching, employing the executable 
portion, for a transaction approval device associated with the 
requesting terminal. If the transaction approval device is 
detected, the method further includes employing the trans- 45 
action approval device to approve the transaction request. If 
the transaction approval device is not detected, the method 
also includes employing an input device associated with the 
requesting device to approve the transaction request. The 
method additionally includes transmitting, using the request- 50 
ing device, an approved transaction request to the server to 
complete the electronic transaction. The approved transac- 
tion request signifies an approval of the transaction request 
by a user via at least one of the transaction approval device 
and the input device. 55 

These and other advantages of the present invention will 
become apparent upon reading the following detailed 
descriptions and studying the various figures of the draw- 

^ 60 

BRIEF DESCRIPTION OF THE DRAWINGS 
To facilitate discussion, 

FIG. 1 shows a prior art electronic transaction system, 
including an automated teller machine (ATM). 55 

FIG. 2 illustrates, in accordance with one embodiment of 
the present invention, a portable electronic authorization 
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device (PEAD), representing the apparatus for securely 
approving transactions conducted vis-a-vis an electronic 
transaction system. 

FIG. 3A shows, in one embodiment of the present 
invention, a simplified schematic of the PEAD of FIG. 2. 

FIG. 313 shows, in one embodiment, the format of repre- 
sentative transaction approval data. 

FIG. 4 illustrates, in accordance with one embodiment of 
the present invention, a logic block schematic of the PEAD. 

FIG. 5 A represents, in accordance with one embodiment 
of the present invention, a high level hardware implemen- 
tation of the PEAD. 

FIG. 513 illustrates one implementation of a PEAD 
wherein the PEAD circuitries are implemented on an IC. 

FIG. 5C represents an external view of the PEAD of FIG. 
5B after being embedded in a card-like package. 

FIG. 6 A illustrates an external view of the PEAD in 
accordance with a preferred embodiment of the present 
invention. 

FIG. 6B illustrates, in a simplified manner and in accor- 
dance with one aspect of the present invention, the hardware 
for implementing the PEAD of FIG. 6A 

FIGS. 7A-B are flowcharts illustrating, in accordance 
with aspects of the present invention, the approval technique 
employing the inventive PEAD. 

FIG. 8 is a flowchart illustrating, in accordance with one 
aspect of the present invention, steps involved in encrypting 
transaction approval data using a public key cryptography 
technique. 

FIGS. 9A-B illustrate exemplary electronic transaction 
systems, including a transaction approval device, to facili- 
tate discussion other aspects of the invention whereas a 
transaction program is employed to complete the electronic 
transaction. 

FIG. 10 illustrates an exemplary flowchart of a computer 
implemented process which, in accordance with one 
embodiment of the present invention, permits a downloaded 
transaction program to complete an electronic transaction at 
the requesting device. 

FIG. 11 illustrates an exemplary transaction request to 
facilitate discussion. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

FIG. 2 illustrates, in accordance with one embodiment of 
the present invention, a portable electronic authorization 
device (PEAD) 200, representing the apparatus for securely 
approving transactions conducted vis-a-vis an electronic 
transaction system. With reference to FIG. 2, requesting 
device 202 may initiate a transaction approval process with 
PEAD 200 by transmitting to PEAD 200, via communica- 
tion port 204, a transaction request pertaining to a proposed 
transaction. Requesting device 202 may represent, for 
example, an ATM machine, a computer terminal in a 
network, an automated library check-out terminal, a portable 
device, hand-held device or similar devices for permitting 
the user to transact business with the electronic transaction 
system. The proposed transaction may be, for example, a 
sale transaction of a particular item for a certain amount of 
money. The transaction request itself may include, for 
example, the transaction ID, the merchant's name, the 
merchant's ID, the lime of the proposed purchase, and the 
like. In one embodiment, the transaction request from 
requesting device 202 may be encrypted for enhanced 
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security but this is not required. Data pertaining to the 
proposed transaction reaches PEAD 200 via path 206 in 
FIG. 2. 

Port 204 may represent an infrared port to facilitate 
infrared communication with PEAD 200. Alternatively, port 5 
204 may represent a wireless port for facilitating wireless 
communication. Port 204 may even represent a contact-type 
connection port, such as a magnetic read/write mechanism 
or a plug having electrical contacts for directly plugging 
PEAD 200 into port 204 to facilitate communication. Other 10 
techniques to facilitate communication between requesting 
device 202 and PEAD 200 are readily appreciable to those 
skilled. 

The data pertaining to proposed transaction(s) may then 
be reviewed by the user, either on a screen 208 of requesting 35 
device 202 or optionally on a display screen provided with 
PEAD 200 (not shown in FIG. 2). If the user approves the 
transaction, e.g., a purchase of an item for a given amount 
of money, the user may then signify his approval by acti- 
vating a switch 210 on PEAD 200, which causes an approval "° 
message to be created with the user's identification data, 
encrypted and transmitted back to requesting device 202 via 
path 212. If the transaction is not approved, the user may 
simply do nothing and let the transaction request times out 
after an elapsed time or may activate another switch on 25 
PEAD 200 (not shown in FIG. 1), which causes a reject 
message, either encrypted or non-encrypted, to be transmit- 
ted back to the requesting device 202 via path 212. 

The present invention is different from the prior art ^ Q 
technique of FIG. 1 in that the user is required in the prior 
art to enter his identification data into the electronic trans- 
action system, e.g., into ATM 100, to authenticate himself. 
In contrast, the present invention keeps the identification 
data related to the user secure within PEAD 200 at all times. ^ 
Transaction approval occurs within PEAD 200, and the data 
representing such approval is encrypted, again within PEAD 
200, prior to being transmitted to the electronic transaction 
system, e.g., to requesting device 202 in FIG. 2. 

Accordingly, even if the approval data is intercepted, its 40 
encryption would prevent unauthorized users from employ- 
ing the identification data for illicit purposes. If public key 
cryptography is employed to encrypt the approval data, the 
user's private key is also always kept within PEAD 200. 
Since the user's private key is required for encryption and is 45 
unknown to others, even to the electronic transaction system 
in one embodiment, the encrypted approval data, if 
intercepted, would be useless to unauthorized third parties 
even if the approval data can be deciphered using the user's 
public key. Again, this is different from prior art authenti- 50 
cation techniques wherein encryption takes place within the 
electronic transaction system and requires the entry of the 
identification data and/or reading the user's private key from 
the ID card such as an ATM card, a credit card, and the like. 
As mentioned earlier, the fact that the prior art electronic 55 
transaction system requires this identification data and/or 
user's private key exposes these data to risks, e.g., if the 
requesting device is not secure or open to data interception 
via software or hardware. 

As another difference, the present invention employs the 60 
circuitries within the portable electronic authorization 
device (PEAD) to perform the approval and encryption of 
the transaction approval data within the PEAD itself. In 
contrast, prior art data cards are essentially passive devices. 
For example, prior art ATM cards or credit cards only has a 65 
magnetic stripe for storing account information and do not 
have any facility to perform approval and/or encryption of 
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the transaction approval data. While smart cards or IC cards, 
which are currently being developed, may contain electronic 
circuitries, current standards for their implementation still 
requires a reader associated with the requesting device to 
read out the identification data and/or user's private key in 
order for the requesting device to perform any approval 
and/or encryption. As mentioned earlier, the transmission of 
these data to the requesting device unnecessarily exposes 
these data to risks of theft and/or unauthorized interception 
once transmitted. 

It should be borne in mind at this point that although 
public key cryptography is discussed throughout this dis- 
closure to facilitate ease of understanding and to highlight a 
particular aspect of the invention, the overall invention is not 
limited to any particular cryptography algorithm and may be 
implemented using any conventional cryptography 
technique, including public key cryptography algorithms 
such as RSA, Diffie-Hellman, other discrete logarithm 
systems, elliptic curve systems, or the like. For additional 
information on some of the different public key cryptogra- 
phy techniques, reference may be made to, for example, the 
IEEE P1363 Working Draft dated Aug. 22, 1996, available 
from IEEE Standards Dept. 345 East 1 th Street, New York, 
N.Y 10017-2349. 

As mentioned, transaction approval in the prior art occurs 
within the electronic transaction system. In contrast, the 
present invention allows transaction approvals to occur 
within PEAD 200. The fact that transaction approvals occur 
entirely within PEAD 200 provides many advantages. By 
way of example, this feature eliminates the need to have, in 
one embodiment, the identification data and/or the user's 
private key in the requesting device. The fact that transaction 
approvals occur entirely within PEAD 200 (using the user 
identification data and/or the user's private encryption key 
that are always kept secure within PEAD 200) substantially 
enhances the confidentiality of the user identification data 
and the user's private key, as well as the integrity of the 
transaction approval process. 

Since approval occurs entirely within PEAD 200, the user 
identification data that is employed to authenticate transac- 
tions may be more complicated and elaborate to ensure 
greater security. By way of example, the user identification 
data may be more elaborate than a simple password and may 
include any of the user's name, his birth date, his social 
security number, or other unique biometrics or unique 
identifying data such as fingerprint, DNA coding sequence, 
voice print, or the like. In contrast, prior art authentication 
techniques limit the user identification data to simple 
patterns, e.g., simple password of few characters, that are 
easily memorized by the user since more elaborate identi- 
fication data may be too difficult to remember or too 
cumbersome to manually enter. Furthermore, even if the 
complicated ID data may be stored in the prior art data card, 
it is still required to be read into the requesting device of the 
electronic transaction system, again exposing this data to 
interception or theft once read. 

Additional safeguards, which will be described in detail 
herein, may also be provided to prevent access, whether 
electronically or by physical means, to the user identification 
data and/or the user's private key within PEAD 200. Since 
the identification data and/or the user's private key are never 
exposed, security risks to the these data are substantially 
minimized. 

FIG. 3A shows, in one embodiment of the present 
invention, a simplified schematic of PEAD 200 of FIG. 2, 
including switch 210. Data path 206 is provided for receiv- 
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ing transaction requests from the electronic transaction 
system, and data path 212 is provided for transmitting 
transaction approval data back to the electronic transaction 
system. It should be borne in mind that although two data 
paths are discussed herein for ease of understanding, these 5 
data paths and other data paths herein may, in one 
embodiment, represent logical data paths and may be imple- 
mented via a single physical data connection. Likewise, the 
different ports herein may represent, in one embodiment, 
logical data ports for ease of understanding and may in fact 10 
be implemented using a single physical port. 

When a transaction request, e.g., a withdrawal transaction 
from an ATM machine in the amount of $200.00, is trans- 
mitted via data path 206 to PEAD 200, this transaction is 
received by encryption logic 300. At this point, the user may 15 
review the proposed transaction, e.g., via the display screen 
or audio output provided with the electronic transaction 
system and/or PEAD 200, and has a choice to either approve 
or disapprove the proposed transaction. If the user approves 
the transaction, he may, in one embodiment, activate a 20 
switch 210, which causes the transaction approval data to be 
created and then encrypted by encryption logic 300 prior to 
being transmitted back to the electronic transaction system 
via path 212. 

Note that the user identification data block 302, which is 25 
employed in the transaction approval process, is not directly 
coupled to paths 206 and 212. In other words, the memory 
portion storing the user identification data is intentionally 
decoupled from the input and output ports of PEAD 200 to 
prevent direct access thereto. 30 

If access to user identification data 302 is desired, e.g., to 
approve a transaction, the access can only be made by 
encryption logic block 300. Likewise, it is not possible to 
directly access the memory portion 304, which stores the ^ 
user's private key. If access to user's private key 304 is 
desired, e.g., to encrypt the transaction approval data, the 
access can only be made by encryption logic block 300. It 
should be borne in mind that although user identification 302 
and user's private key 304 are shown stored in different 4Q 
memory portions, such illustration is made for ease of 
understanding and both of these may in fact be stored, in one 
embodiment, at different addresses on the same memory 
module. 

In some cases, the transaction approval data requires the 45 
inclusion of certain pieces of identification data 302. For 
example, a transaction embodied in the transaction request 
from the electronic transaction system may be appended 
with data representative of an "electronic signature"' prior to 
being encrypted and retransmitted back to the electronic 5 0 
transaction system. FIG. 3B shows, in one embodiment, the 
formal of representative transaction approval data 350. With 
reference to FIG. 3B, transaction data 352, representing a 
portion of or the entire transaction request received from the 
electronic transaction system, is appended with certain user 55 
identification data 354 and optionally a time stamp 356. The 
formation of transaction approval data 350 only occurs if the 
transaction request has already been approved by the user. 
Once appended, transaction approval data 350 is then 
encrypted prior to being retransmitted back to the electronic 60 
transaction system. 

In some cases, it may be desirable to encrypt the trans- 
action request prior to transmission to the PEAD to further 
enhance security. For example, certain transaction partners, 
e.g., vendors or other users on the computer network, may 65 
wish to keep the information within a transaction request 
confidential and may prefer to encrypt the transaction 
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request before furnishing it to the PEAD. Data encryption is 
also desirable when, for example, the user identification data 
and the user's private key is written into a blank PEAD for 
the first time to configure a PEAD that is unique to a given 
user. The configuration data pertaining the user identifica- 
tion data and the user's private key, while must be written 
only once into PEAD 200 by the issuer of PEAD 200, is 
preferably encrypted to render them less vulnerable to theft. 
Issuers of PEAD 200 may represent, for example, credit card 
issuers, the government, or any other institution with whom 
the user maintains an account. 

FIG. 4 illustrates, in accordance with one embodiment of 
the present invention, a schematic of PEAD 200 of FIG. 2. 
The PEAD 200 of FIG. 4 further employs decryption logic 
for receiving the encrypted configuration data and optionally 
the encrypted transaction requests. In FIG. 4, encryption 
logic 300, user's private key 304, and data paths 206 and 212 
are arranged and function substantially as discussed in 
connection with FIG. 3A. 

Transaction requests are normally non-encrypted, i.e., 
they are received and processed in the manner discussed in 
connection with FIG. 3 A. For highly sensitive transactions, 
however, the transaction requests may be encrypted and 
transmitted to PEAD 200 via data path 206 and input into 
decryption logic 402 to be decrypted. If a public key 
cryptography is employed, the encrypted transaction 
requests may be decrypted with a transaction partner public 
key 404. 

Once decrypted, the transaction request is then displayed 
to the user for approval. The transaction approval data may 
be furnished to encryption logic 300 via path 406 to be 
encrypted if approved, e.g., responsive to the activation of 
switch 210. The encryption is preferably performed with the 
user's private key 304 if a public key cryptography tech- 
nique is employed, and the encrypted transaction approval 
data is then transmitted back to the electronic transaction 
system via data path 212. 

As configuration data typically includes sensitive user 
identification data and user's private key, it is often 
encrypted prior to being transmitted to PEAD 200 via data 
path 408. The encrypted configuration data is received by 
decryption logic 402 and decrypted therein prior to being 
written into user identification data block 410 and user's 
private key block 304. If public key cryptography is 
employed, the encrypted configuration data may be 
encrypted by the issuer's private key in the electronic 
transaction system prior to transmission and decrypted once 
received by PEAD 200 with an issuer public key 412. 

Note that once the configuration data is decrypted and 
written into user identification data block 410 and user's 
private key block 304, the user identification data and user's 
private key can only be accessed subsequently by encryption 
logic 300. Also note that there is no direct connection from 
any of the I/O data paths, e.g., data path 206, 212, or 408, 
to user identification data block 410 as well to user's private 
key block 304. Advantageously, the sensitive user identifi- 
cation data and user's private key therein are not susceptible 
to access from outside once written into respective blocks 
410 and 304 (which may, in one implementation, simply 
represent memory blocks in PEAD 200's memory). 

Additionally, the user identification data and the user's 
private key cannot be updated by those not having the 
issuer's private key. As represented in FIG. 4, data can only 
be written into user's private key block 304 and user 
identification block 410 after it is decrypted via decryption 
logic 402 with issuer public key 412. Accordingly, unless the 
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updated configuration data has been encrypted using the 
issuer's private key (which is presumably highly secure), the 
updated configuration data will not be decrypted and written 
into respective blocks 304 and 410. Of course if the con- 
figuration data within blocks 304 and 410 cannot be updated 5 
physically, e.g., they are stored using memory that can be 
written only once such as PROM (programmable read-only 
memory), WORM (write once, read many), or the like, the 
security consideration associated with unauthorized alter- 
ation of configuration data is substantially eliminated. 10 

If a greater level of security is desired, the user's private 
key may be optionally be scrambled or randomized prior to 
being written into user's private key block 304 by optional 
scrambler/descrambler logic 413. Scramble r/descrambler 
logic 413 may, in one embodiment, receive the user's private ^ 
key, which is furnished by the institution that issues PEAD 
200 to the user, and scrambles and/or randomizes it to 
generate yet another user's private key and a corresponding 
user's public key. This scrambled/randomized user's private 
key is then stored in user's private key block 304, which is 20 
now unknown even to the issuer of PEAD 200, and the 
corresponding user's public key may be made known to the 
issuer and/or the transaction partners to facilitate transac- 
tions. Advantageously, there is no other copy of the 
scrambled/randomized user's private key anywhere else 25 
beside within user's private key block 304. 

In an alternative embodiment, there may be employed an 
optional key generation logic 414 which, responsive to a 
request from the issuing institution, generates the user's 
private key and the user's public key on its own, i.e., without 30 
first requiring the receipt of a user's private key from the 
issuing institution and randomizing it. The generated user's 
private key is then stored in private key block 304 and the 
public key is made known to the issuing institution and/or 
the transaction partners to facilitate transactions. In this 35 
manner, no version of the user's private key, whether 
randomized or not, exists outside the PEAD itself. As can be 
appreciated by those skilled in the art, the use of key 
generation logic 414 further enhances the confidentiality of 
the user's private key. 40 

FIG. 5A represents, in accordance with one embodiment 
of the present invention, a high level hardware implemen- 
tation of PEAD 200. As shown in FIG. 5A, PEAD 200 
includes logic circuitry 502, which may represent a central 45 
processing unit such as a microprocessor or a 
microcontroller, discrete logic, programmable logic, an 
application-specific integrated circuit (ASIC), or the like, for 
implementing encryption logic 300 of FIG. 2 and optionally 
decryption logic 402 of FIG. 4. 5Q 

Program/data memory 504 stores, among others, the 
codes which operate PEAD 200 as well as the user identi- 
fication data and the user's private key. Program/data 
memory 504 is preferably implemented using some form of 
non-volatile memory (NVM) such as flash memory, electri- 55 
cally programmable read-only memory (EPROM), electri- 
cally erasable, programmable read-only memory 
(EEPROM), or the like. Temporary memory 506 serves as a 
scratch pad for calculation purposes and for temporary 
storage of data, and may be implemented using some form 60 
of random access memory (RAM) such as static RAM or 
dynamic RAM, which are known in the art. Alternatively, 
either optical memory, magnetic memory, or other types of 
memory may be employed to implement program/data 
memory 504 and/or temporary memory 506. 65 

A bus 508 couples program/data memory 504 and tem- 
porary memory 506 with logic circuitry 502. Communica- 
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tion port 510 represents the communication gateway 
between PEAD 200 and the electronic transaction system 
and may be implemented using infrared technology, wireless 
RF technology, a magnetic read/write head, a contact-type 
plug for facilitating serial or parallel data transmission, or 
the like. Communication port may also represent, in one 
embodiment, a PC card port (popularly known to those 
skilled as a PCMCIA card). Data path 206 inputs transaction 
requests into logic circuitry 502 while data path 212 outputs 
transaction approval data from logic circuitry 502 to the 
electronic transaction system. Optional data path 408, which 
has been described in FIG. 4, inputs configuration data into 
PEAD 200 to write the user identification data and the user's 
private key into program/data memory 504 to uniquely 
configure PEAD 200 to a particular user. 

Again, note that access to program/data memory 504 and 
the data therein (e.g., the user identification data and the 
user's private key) can only be made by logic circuitry 502. 
For example, the user identification data and the user's 
private key can only be written into program/data memory 
504 if this data has been properly encrypted with the issuer's 
private key. Access to these memory blocks for writing 
thereto may also be restricted by logic circuitry 502 under 
appropriate software and/or firmware control. 

Similarly, reading the user identification data and access- 
ing the user's private key can only be accomplished via the 
encryption logic of logic circuitry 502. The advantages to *» 
security of this aspect has been discussed in connection with 
FIGS. 3A and 4, the most important point being there is 
preferably no direct access to the sensitive user identification 
data and user's private key from the outside. Consequently, 
the confidentiality and security of these data items are 
greatly enhanced with the inventive design. 

Some type of power source, such as a battery, may be 
provided as well. If PEAD 200 is implemented as a single- 
chip design, i.e., substantially all components shown in FIG. 
5A are fabricated on a single die, then power is external to 
the die itself. If contact-type communication is employed, 
e.g., if PEAD 200 must be plugged into the electronic 
transaction system to conduct transactions, power external 
to the entire PEAD may be employed for transaction approv- 
als when plugged in, thereby eliminating the size, weight, 
and cost penalties associated with having a battery onboard 
the portable transaction apparatus. 

In one embodiment, PEAD 200 may be implemented 
using a general purpose portable computing device, such as 
any of the miniaturized portable computers, personal digital 
assistants (PDA's) or portable phones that are currently 
popular. A PDA such as the Apple Newton or 3COM's Palm 
VII, for example, may be employed to implement PEAD 
200. Additionally, portable phones such as the Nokia 7110 
Media Phone, Ericsson R280 SmartPhone or Motorola 
ilOOO plus can be employed to implement the PEAD 200. In 
this case, it is understood that the portable device such as a 
PDA, Media Phone or SmartPhone can be a requesting 
device itself, which communicates a remote electronic trans- 
action system through a wireless network. The PEAD func- 
tionality can be embedded into such a portable requesting 
device. 

FIG. 5B illustrates one implementation of a PEAD 
wherein the circuitries are implemented on an IC. In FIG. 
5B, components having like reference numbers to compo- 
nents in FIG. 5A have similar functions. Data paths 408, 
206, and 212, which have been described in connection with 
FIG. 5 A, is coupled to a serial I/O circuit 520, which 
facilitates data transmission and receipt in a serial manner on 
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data path 522 between PEAD 200 and the electronic trans- 
action system. Vcc pin 524 and ground pin 526, which 
provide power to PEAD 200 of FIG. 5B, are also shown. 

FIG. 5C represents an external view of the PEAD of FIG. 
5B after being embedded in a card-like package for ease of 5 
carrying and insertion into a serial I/O port of the electronic 
transaction system. Card 550, which embeds the integrated 
circuit implementing the inventive PEAD, includes, in one 
embodiment, four external contacts. External serial contacts 
552 and 554 carry data and ground respectively to facilitate Q 
serial communication with a serial device of an electronic 
transaction system. External Vcc contact 524 and external 
ground contact 526, which supply power to the PEAD as 
discussed in connection with FIG. 5A, are also shown. When 
card 550 is inserted into an electronic transaction system, it J5 
is powered through external contacts 524 and 526, thereby 
enabling the PEAD circuitries therein to receive transaction 
requests via external serial contacts 552 and 554, approve 
the requests within the PEAD if appropriate, encrypt trans- 
action approval data within the PEAD circuitries, and seri- ^ 0 
ally communicate the encrypted transaction approval data to 
the electronic transaction system via external serial contacts 
552 and 554. 

FIG. 6A represents an external view of a PEAD in 
accordance with a preferred embodiment of the present 75 
invention. PEAD 200 of FIG. 6Ais preferably implemented 
as a small, self-containing package that is sufficiently rug- 
geclized'for daily use in the field. Preferably, PEAD 200 of 
FIG. 6 A is small enough to be comfortably carried with the 
user at all times, e.g., as a key chain attachment or a small 30 
package that can easily fit inside a purse or a wallet. The 
physical enclosure of PEAD 200 is preferably arranged such 
that the content will be tamper-proof (i.e., if it is opened in 
an unauthorized manner then the user's private key and/or 
the user identification data will be destroyed or the PEAD ^ 
will no longer be able to approve transactions). By way of 
example, the enclosure may be arranged such that if it is 
opened, there is a change in the flow of current in a current 
path, e.g., either the existing current flow is interrupted or a 
current path that has been idle starts to flow. The change in 40 
the flow of current may then force RESET the circuitry, 
including erasing the private key in the memory. 

There is shown an infrared communication port 602 for 
receiving and transmitting data vis-a-vis the electronic trans- 
action system. A small on/off switch 604 permits the user to 45 
turn off the PEAD to conserve power when not in use. 
Approve button 606 permits the user to signify approval of 
a proposed transaction. Optional skip button 608 permits the 
user to indicate rejection of a particular transaction. Skip 
button 608 may be omitted since a transaction request may 50 
be understood, in some embodiment, as not being approved 
if approve button 606 is not activated within a given period 
of time after receiving the request. 

Optional display 610 may be implemented using any type 
of display technology such as liquid crystal technology. 55 
Displays 610 displays, among others, the transaction being 
proposed for approval. Display 610 may be omitted if 
desired, in which case the transaction may be viewed, for 
example, at a display associated with the electronic trans- 
action system itself or by audio output on the PEAD. 60 
Optional user authentication mechanism 612 prevents 
PEAD 200 from being used for approving transactions 
unless the user is able to identify himself to PEAD 200 as the 
rightful and authorized user. Optional user authentication 
mechanism 6.12 may require the user to enter a password, to 65 
finish a fingerprint or a voice print, or other biometrics 
and/or identifying characteristics specific to the authorized 
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user before PEAD 200 can be activated and employed for 
approving transactions. The PEAD 200 can be built-in a 
portable phone such that port 602 can be a wireless com- 
munication and/or infrared port, display 610 can be a display 
on the portable phone, and buttons 606 and 608 are button 
keys on the portable phone key pad. 

For example, user authentication mechanism 612 can be 
a Fingerchip FC 15A140, a thermal silicon fingerprint 
sensor from Thomson-CSF of Totowa, N.J. Since no optics 
or light sources are needed as the finger's own heat produces 
all that is necessary to image the finger print, this imple- 
mentation can be quite compact. In this embodiment, the 
user can authenticate himsellTherself and approve a trans- 
action through PEAD by simply presenting or sweeping 
his/her finger to/across the sensor 606, thereby rendering 
approve button 606 optional. As another example, the 
mechanism 612 can be a FPS110, a capacitive silicon finger 
print sensor from Veridicom of Santa Clara, Calif. 

FIG. 6B illustrates, in a simplified manner and in accor- 
dance with one aspect of the present invention, the hardware 
for implementing PEAD 200 of FIG. 6A. Battery 652 
provides power to the circuitry of PEAD 200. A microcon- 
troller 654 executes codes stored in flash memory 656 and 
employs random access memory 658 for the execution. In 
one embodiment, microcontroller 654, flash memory 656, 
and even random access memory 658 may be implemented 
on a single chip, e.g., a NC68HC05SCXX family chip from 
Motorola Inc. of Schaumburg, 111. such as the 
NC68HC05SC28, or security controller of SLE 22, 44 and 
66 family from Infineon Technologies of San Jose, Calif, 
such as SLE66CX320S. Approve button 606 and optional 
skip button 608 are coupled to microcontroller 654 to permit 
the user to indicate approval or rejection of a particular 
transaction displayed using display circuitry 660. Commu- 
nication to and from the electronic transaction system is 
accomplished under control of microcontroller 654 via an 
infrared transceiver 662. Power switch 664 permits the user 
to power off PEAD 200 when not in use to conserve power 
and to prevent accidental approval. 

FIG. 7A is a flowchart illustrating, in accordance with one 
aspect of the present invention, the approval technique 
employing the inventive PEAD. In step 702, a transaction 
request is received at the PEAD from the requesting device 
associated with the electronic transaction system. In step 
704, the user has the option whether to approve or disap- 
prove the transaction proposed. If not approved, e.g., either 
by activating the skip button of the PEAD or simply allow- 
ing the request to time out, nothing will be done. 

On the other hand, if the user approves the proposed 
transaction, the user may activate the approve button to 
create transaction approval data. The transaction approval 
data is then encrypted in step 708 within the PEAD. In step 
710, the encrypted transaction approval data is transmitted 
to the requesting device of the electronic transaction system 
after being encrypted. 

FIG. 7B is a flowchart illustrating, in accordance with 
another aspect of the present invention, the approval tech- 
nique employing the inventive PEAD. In step 752, a trans- 
action request is received at the agent server from the 
requesting device associated with the electronic transaction 
system. In step 754, the user has the option whether to 
approve or disapprove the transaction proposed at the 
PEAD. If not approved, e.g., either by activating the skip 
button of the PEAD or simply allowing the request to time 
out, nothing will be done. 

On the other hand, if the user approves the proposed 
transaction, the user may activate the approve button to 
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create transaction approval data. The transaction approval 
data is then encrypted in step 758, which can occur either 
within the PEAD or the agent server or both. In step 760, the 
encrypted transaction approval data is transmitted to the 
requesting device of the electronic transaction system after 
being encrypted. 

FIG. 8 is a flowchart illustrating, in accordance with one 
aspect of the present invention, the steps involved in 
encrypting transaction approval data using public key cryp- 
tography. In step 802, the transaction approval data package 
is created. As discussed earlier in connection with FIG. 3B, 
the transaction approval data may be created by appending 
any necessary user identification data to a portion of or the 
entire transaction request. Optionally, a time stamp may also 
be appended thereto. In step 804, the transaction approval 
data is encrypted using the user's private key, which is 
preferably kept secured at all times within the PEAD. 
Thereafter, the encrypted transaction approval data is trans- 
mitted back to the electronic transaction system. 

In accordance with one aspect of the present invention, it 
is recognized that even if the encrypted transaction approval 
data is intercepted and decrypted for analysis by a third 
party, it is not possible to bypass the security features of the 
invention as long as the user's private key or the user 
identification data is secure. As mentioned earlier, since the 
user identification data is not accessible externally, it is 
always secure within the PEAD. This is unlike the prior art 
wherein the user is required to enter the identification data, 
e.g., password, at the electronic transaction system and risks 
exposure of this sensitive data. 

Even if the user identification data is compromised, 
transaction approval still cannot take place unless there is 
possession of the user's private key. It would be useless to 
intercept the encrypted transaction approval data even if one 
can decrypt it using the user's public key since the transac- 
tion partner, e.g., the merchant requesting approval of the 
transaction, will not accept any transaction approval data not 
encrypted using the user's private key. Again, since the 
private key is not accessible externally, it is always secure 
within the PEAD. This aspect of the invention has great 
advantages in performing on-line transactions since the 
user's private key no longer has to be stored in a vulnerable 
computer file in a workstation, which may be accessible by 
other parties and may be difficult to conveniently tote along 
for other authentication tasks. 

The fact that the PEAD is implemented in a small, 
portable package makes it convenient and comfortable for 
the user to maintain the PEAD within his possession at all 
times. Even if the PEAD is physically stolen, however, the 
optional user authentication mechanism, e.g., user authen- 
tication mechanism 612 of FIG. 6A, provides an additional 
level of protection and renders the PEAD useless to all but 
the properly authenticated user. Of course the user can 
always notify the issuer of the PEAD if the PEAD is stolen 
or lost, and the issuer can inform transaction partners to 
refuse any transaction approval data encrypted with the 
user's private key of the stolen PEAD. 

The fact that the transaction approval data includes the 
time stamp, the merchant's name, the amount approved, and 
other relevant data also enhances the integrity of the trans- 
action approval process. If the merchant inadvertently or 
intentionally submits multiple transaction approvals to the 
issuer, the issuer may be able to recognize from these data 
items that the submissions are duplicates and ignore any 
duplicate transaction approval data. For example, the issuer 
may recognize that is it unlikely for a user to purchase 
multiple identical dinners at the same restaurant at a given 
time and date. 
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It should be noted that while the discussion above has 
focused on transaction approvals, it should be apparent to 
those skilled that the PEAD may be employed to conduct 
any kind of transaction vis-a-vis an electronic transaction 
system any time secured data transmission from the user to 
the electronic transaction system is preferred. For example, 
the PEAD may be employed for logging into highly sensi- 
tive computer systems or facilities. When so implemented, 
the computer terminal with which the PEAD communicates 
may be equipped with an infrared port, a magnetic reader 
port, or a contact-type plug for communication with the 
PEAD. The user may then employ the PEAD to perform any 
type of authentication tasks online. 

As a further example, the PEAD may be employed to 
"sign" any computer file for authentication purposes (e.g., to 
authenticate the date or the user). The transaction approval 
data may then be saved along with the file to be authenti- 
cated for future reference. Note that the transaction authen- 
tication data is again tamper-proof since any transaction 
authentication data not encrypted using the user's private 
key will not be accepted as authentic. Also, it should be 
apparent that if the PEAD is employed to approve only 
predefined transactions, the transaction data may be stored 
in advance within the PEAD and do not need to be received 
from externally by the PEAD. 

In another embodiment, the invention relates to tech- 
niques for conducting electronic transactions within an 
electronic transaction system such that confidentiality, 
authentication, integrity, and non-repudiation are substan- 
tially assured. It is observed that successful electronic trans- 
actions (e.g., those conducted over a computer network such 
as the internet) have four major requirements: 
confidentiality, authentication, integrity, and non- 
repudiation. In the prior art, confidentiality is typically 
addressed by employing encryption to encrypt data between 
the user's computer and the remote server. One such encryp- 
tion technique employed by NetScape Corp. of Mountain 
View, Calif, involves the use of a Secure Socket Layer 
(SSL), which essentially utilizes encryption (e.g., public key 
encryption) for the point-to-point communication over an 
open network. 

Although encryption techniques like SSL can, to a certain 
degree, ensure that the transmission of a transaction is 
secure, there is however no mechanism to authenticate the 
identity of the person who actually conducted the transaction 
(i.e., there is an authentication deficiency). By way of 
example, if an unauthorized person, after cracking a legiti- 
mate user's password, employs that legitimate user's com- 
puter (which may be SSL-enabled) to conduct a transaction 
to the detriment of the legitimate user, there is no mechanism 
to determine during or after the transaction is completed 
whether the person conducting the transaction in question is 
an unauthorized person or the legitimate user. Even if the 
legitimate user himself conducted the transaction, the 
authentication deficiency renders it impossible to guarantee 
non-repudiation, as it is difficult for the vendor to prove that 
it is indeed the legitimate user who conducted the transac- 
tion in question. Furthermore, although the transmission is 
relatively secure using a secured transmission facility such 
as SSL, the transmitted data (such as terms in a contract or 
purchase order) may be susceptible to being modified after 
it is decrypted by personnel at the receiving end. 

In accordance with one aspect of the present invention, 
there is provided a software-implemented technique for 
performing electronic transactions in a manner such that the 
aforementioned requirements may be better addressed. In 
one embodiment, the electronic transaction technique pro- 
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posed herein employs a transaction program (TP), which is 
essentially a program or an applet that may be downloaded 
into the requesting device (e.g., device 202) from a server 
and executed at the requesting device to carry out the 
electronic transaction. By way of example, computer lan- 5 
guages such as Java by Sun Microsystems Inc. of Mountain 
View, Calif, or ActiveX by Microsoft Corp. of Redmond, 
Wash, or HDML (Handheld Device Markup Language) by 
Unwired Planet, Inc. of Redwood City, Calif., may be 
employed although the electronic transaction technique pro- 10 
posed herein may be implemented by any other suitable 
computer language as well. 

Once downloaded, the TP may be configured in any 
suitable manner for execution, preferably either as a stand- 
alone program or as a plug-in into one of the internet 15 
browsers (e.g., NetScape, Internet Explorer or Micro- 
browser by the aforementioned Netscape Corp., Microsoft 
Corp. and Phone.com, Inc. respectively). 

To facilitate discussion of the advantages and features of 
this aspect of the present invention, FIG. 9A depicts an ~° 
electronic transaction network 900 including server 902, 
network 904, and requesting device 906. A transaction 
approval device, such as a PEAD 908 is also shown. 
Requesting device 906, as mentioned earlier, may represent 
any device for permitting the user to transact business with -:> 
the electronic transaction system. Preferably, the requesting 
device is implemented by a suitable computer terminal that 
is capable of communicating with server 902 through net- 
work 904, which may represent a LAN, WAN, or the 
Internet. The computer terminal itself may be, for example, 30 
a desktop device, a portable device, a hand held device, or 
otherwise, including those implementing the Windows, 
Macintosh, Unix platforms or those capable of supporting a 
browser program. If the requesting device is a portable 
device, or hand -held device, then the PEAD 908 can be 33 
embedded into the requesting device 906. Also, the com- 
munication link between the requesting device 906 and the 
server 902 can be a wireless communication link as shown 
in FIG. 913. 

To carry out an electronic transaction in accordance with 
one embodiment of this invention, the transaction program 
(TP) is preferably downloaded from the vendor's or service 
provider's server 902 into requesting device 906 (step 1002 
of FIG. 10). The TP may include an executable portion as 45 
well as data related to the transactions for the user's input, 
approval, and/or authentication. 

By way of example, if the transaction involves the pur- 
chase of an appliance, the TP may download data pertaining 
to the model, price, and the like. FIG. 11 depicts one 5Q 
exemplary transaction request for the purchase of appli- 
ances. As another example, if the transaction involves the 
purchase or sale of securities (such as stocks or bonds), the 
TP may be downloaded with data pertaining to the securities 
to be transacted. Of course, the transaction request may be 55 
relate to any type of transaction, including those that do not 
involve the exchange of cash or credit for goods or services 
(such as document transfer). 

In return, the TP preferably receives user's data from the 
user (e.g., the user's identification data, any data which may 60 
be required for the proposed transaction such as the address 
information, quantity information, size information, method 
of payment, credit card number, account number, and the 
like), and an indication of approval of the transaction. 

It should be appreciated that the specific data to be 65 
downloaded may vary depending on the nature of the 
transaction to be performed. Likewise, the data to be 



,922 Bl 

16 

received by the TP from the user may vary with applications. 
In some cases, if the user has already supplied the vendor 
with some of the requested data in the past (such as the 
user's address), the TP may not ask for the same data again 
or may simply present the already supplied data to the user 
for validation and/or possible editing. 

The executable portion of the TP preferably includes 
codes to automatically detect the presence of a transaction 
approval device (such as the aforementioned PEAD, a smart 
card device, a Credit Card Reader, or the like) so that the TP 
can employ the transaction approval device to complete the 
transaction (step 1004 of FIG. 10). By way of example, the 
downloaded code may be configured to search the user's 
computer to detect whether a transaction approval device 
has been installed or to use the user's computer communi- 
cation port(s) to query for the existence of a transaction 
approval device that may be external of the user's computer. 
If the PEAD is embedded in a portable requesting device, 
then the PEAD detection is performed in the portable 
requesting device. 

The executable portion of the TP may also include codes 
to obtain, through an appropriate input device, the user's 
identification for authentication. By way of example, the TP 
may obtain the user's signature, the user's facial image, 
finger print, voice print, DNA coding sequence through a 
tissue sample, or other unique biometrics or other unique 
identifying data. The obtained user's identification facili- 
tates non-repudiation, i.e., it facilitates identification of the 
identity of the person conducting the transaction so that 
fraud detection may be improved or deniability may be 
minimized. Of course some of the identification data may 
already exist in the PEAD and if such identification data is 
obtained from the PEAD, the obtained identification may 
indicate at least that the person performing the transaction 
on the requesting device also has access to the PEAD. 

It should be appreciated, however, that some or all of the 
executable portion may not need to be downloaded every 
time and may be loaded once into the requesting device for 
subsequent use. Of course, the fact that the executable 
portion of the TP is downloadable, and preferably down- 
loadable with a transaction to be approved, greatly simplifies 
the task of enabling electronic transactions even when the 
transaction approval device is updated (e.g., with new 
technologies), the communication protocol between the 
transaction approval device and the requesting device 
changes, or when a new transaction approval device is 
installed with the requesting device. In these cases, the TP 
containing the updated codes appropriate for the updated/ 
new transaction device and/or protocol may be downloaded 
into the requesting device, either automatically with a trans- 
action or upon request by the user, to enable electronic 
transactions. 

For ease of discussion, assume that the requesting device 
(e.g., the user's computer) is PEAD-enabled. In this case, the 
TP may communicate with the PEAD, once it has detected 
the presence of such a device, to obtain approval data, 
authentication data and/or any other required user-supplied 
information in accordance with techniques discussed (step 
1006 of FIG. 10). By way of example, the TP may employ 
the communication port in the requesting device for com- 
munication with the PEAD. As any of the required user 
authentication and user-supplied data may be stored in the 
PEAD, the user's approval, authentication and/or other 
user-supplied data may be encrypted by the PEAD and 
transmitted back to the requesting device wherein the TP 
may employ such data for responding to the transaction 
request, including transmitting some or all of the encrypted 
data received from the PEAD back to the server (step 1008 
of FIG. 10). 
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As can be appreciated from the foregoing, the use of the 
PEAD in conjunction with the TP ensures that the electronic 
transaction is confidential since the encryption facilities in 
the PEAD and/or the TP renders the transmission secure. 
Further, the electronic transaction is more securely authen- 5 
licated since the user can be authenticated using the identi- 
fication data within the PEAD (e.g., the aforementioned 
unique biometrics or unique identifying data such as 
fingerprint, DNA coding sequence, voice print, or the like). 

Likewise, if the requesting device is enabled with another 10 
transaction approval device such as a Smart Card reader or 
a credit card reader, the TP may then request that the user 
approve, authenticate, and/or supply the requested data 
using the transaction approval device present (e.g., by insert- 
ing the Smart Card or credit card or other similar apparatus 15 
into the transaction approval device present), either alone or 
in combination with other data entry techniques (e.g., click- 
ing on choices present on the screen, typing, speech input, 
or the like) to complete the transaction data requested. 

On the other hand, if the requesting device is not enabled 20 
with a transaction approval device, the user may still pro- 
ceed with the transaction by authenticating, approving and/ 
or supplying the requested data conventionally using any of 
the aforementioned data entry technique (step 1006 of FIG. 
10). The TP will then preferably (but not necessarily) formal 25 
and/or encrypt the entered data, using, e.g., a public key 
transcription system, to transmit the transaction data back to 
the server to complete the transaction (step 1008 of FIG. 10). 
In this manner, the TP will be backwardly compatible with 
requesting devices that may not be equipped with a trans- 30 
action approval device. 

Note that since the downloaded TP is, in the preferred 
embodiment, endowed with encryption facilities, i.e., the 
encryption codes is included in the downloaded codes in this ^ 
embodiment, the presence of a general purpose encryption 
facility (such as the aforementioned SSL) may not be 
required for secured transmission. In this manner, backward 
compatibility with requesting devices which are not even 
equipped with a secured transmission facility (e.g., the 4Q 
aforementioned SSL) while transmission confidentiality is 
assured. On the other hand, if the requesting device is 
endowed with the general purpose encryption facility (e.g., 
the aforementioned SSL), the presence of the encryption 
codes in the TP may not be required. Of course, it is also 45 
possible to encrypt using both the encryption facility of the 
TP and the general purpose encryption facility (e.g., the 
aforementioned SSL) together to encrypt data transmitted to 
the server. 

It should be noted, however, a transaction conducted in so 
this manner may be less secure than that conducted with a 
transaction approval device such as the PEAD since the 
user's identity may not be authenticated, or verified, to the 
vendor. Because of this, there may be no guarantee of 
non-repudiation since a user can later deny having con- 55 
ducted the transaction in question. Along the same line, the 
data integrity may be less secure since the transaction data 
may be modified once received at the remote server. 

Another implementation of the invention is directed 
toward a service resevation transaction. In this 60 
implementation, the PEAD can perform service reservation, 
transaction and service authorization all in the same device. 
For example, the PEAD can perform a hotel reservation 
through wireless network and Internet and complete the 
transaction by providing the credit information with elec- 65 
Ironic signature performed by the PEAD. Once the hotel 
acknowledges the transaction, the hotel can transmit the 
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service information including room number direction to the 
hotel, etc. as well as the encrypted electronic room key 
through the Internet and wireless network to the PEAD. 
When the user arrives the hotel, he does not need to wait on 
the line for check-in, but rather can go directly to the room 
and use the PEAD pre-stored hotel electronic key to open the 
room door. The PEAD user can also use the PEAD 10 order 
room service through the wireless network and Internet. At 
the end of the stay, the user can check-out through the PEAD 
and received the electronic bill/receipt over the wireless 
network and Internet. For example, the user can check-out of 
the hotel while traveling to the airport to catch a flight. 

Similarly, the PEAD can perform the airline ticket reser- 
vation through the wireless network and Internet. Once the 
transaction is completed using the PEAD, the airline can 
issue the encrypted electronic ticket through the Internet and 
wireless network to the PEAD. When the PEAD user arrives 
the airport, after the security clearance, he can go directly to 
aboard using the PEAD pre-stored electronic ticket to notify 
the gale counter computer that he is the ticket owner through 
the wireless network and Internet. 

Similarly, the PEAD can be used to reserve theater tickets 
and receive the encrypted electronic tickets and service 
information through the wireless network and Internet. The 
PEAD can be used for rental car reservation, key pickup 
service, and even to start the car through an equipped 
Internet controlled ignition system, and car return service. 

Or the Supermarket can issue electronic coupons through 
the Internet and wireless network to the PEAD. When the 
user shops in the Supermarket, he can present the coupons 
over the point of sale counter through the wireless network 
and Internet. 

One of the preferred embodiment is using an Internet 
enabled cellular telephone (e.g. a web phone), a wireless 
PDA or a wireless two way pager to implement the PEAD 
to perform the above applications. The description below 
uses an Internet enabled cellular telephone as example of the 
implementation, and those skilled in the art will understand 
that the same or similar method can be applied to wireless 
PDAs and two way pagers. The Internet enabled cellular 
phone (web phone) can communicate with the Internet 
through a wireless network. For example, currently Sprint- 
PCS provides an Internet phone service using NeoPoint 
1000 web phone. The web phone can access the Internet 
through a wireless gateway, and can contact the hotel's 
Internet reservation system through the wireless network 
and Internet. The software and/or firmware controls the 
PEAD functions running in the web phone is called eSignX 
Agent (or xAgent for short), x Agent is under the user's 
control to contact the hotel reservation transaction system. 
The reservation transaction process includes: (1) the web 
phone (PEAD) sending out the reservation request (optional 
using merchant public key [in the example given here, the 
merchant is the hotel, then it would be the hotel's public key 
or it's certificate] to encrypt the request; optionally using the 
user's private key to sign the request); (2) the Merchant 
acknowledges with the service availability and the cost 
(optionally, this message can be encrypted using the user's 
public key and the hotel's private key); (3) once the user 
approves the transaction, the web phone sends out the 
transaction confirmation with the credit information and 
signed by the user's private key (optionally encrypted with 
the Merchant's public key); (4) once the Merchant validates 
the transaction, the Merchant sends out the service infor- 
mation as well as the service authorization token (the token 
could be the electronic room key in the hotel reservation 
example, the token could be the electronic ticket in the 
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Airline Ticket Reservation and Theater Ticket reservation as Bluetooth and infrared communication port, the described 

examples, or the token could be the Supermarket coupon etc. transaction can be conducted locally through PEAD's Blue- 

The token is optionally encrypted by the user's public key tooth port or infrared port using the same method, 

and Merchant's private key; (5) when the service is \\ is also possible to use an ordinary cellular phone not 

rendered, a service authorization token is to be presented 5 necessarily having web capability to perform both above 

over the point of service (example, hotel room door, airport Service Reservation Transaction and Point-of-Sale Transac- 

boarding gate, or theater entrance, Supermarket check-out ti on by using a remote voice activated or touch tone server, 

counter or rental car etc.) through the wireless network and For example, this is called an Agent Server. The Agent 

Internet; (6) if the service authorization token has been server functions exactly likes the PEAD in a Web phone 

validated at the point of service (e.g. decrypting the token jo except it is not necessarily portable. It operates through the 

using the Merchant's public key successfully) then, the existing voice activated or touch tone interfacing with the 

Merchant can authorize the service (e.g. to open the hotel enc i user through the existing phone network. Once the user 

room, to permit the boarding at the airport gate, to admit registers an xAgent in the Agent Server, the ordinary cellular 

entering the theater, to discount the transaction amount, to phone end user can en j oy an lhe same functionality as the 

ignite a car, etc.) p none user For example, the end user can use the 

In yet another implementation, called a Point-of-Sale or dj narv cellular phone to dial in to the Agent Server to 

Transaction, the PEAD can perform the Point-of-Sale trans- activate h[s own xA t b entering his xAgent password 

action through the wireless network and Internet In the th h yoice activated intefface Qf louch tQQe ^rtm. 

uture the Point-o -Sa e terminal can access the Internet Qnce fe activa can rQs ^ Q a hold Qrder 

through an internal network system or through a dial-up t . , , to , . , r . ■ « * 

phone line, DSL, ADSL, or cable modem, etc The PEAD 20 ^ ckcls ' ^ at a Pomt-ol-sale counter through the Agent 

can be used as the Point-of-Sale transaction device. At the Server > J us < as J f U were runmn S on » Web phone. For 

Point-of-Sale check-out counter, the Point-of-Sale terminal example, the end user can reserve the a hotel room, once the 

can scan in the merchandise barcodes and generate transac- xA § ent § ets the approval from the user's cellular phone, the 

tion information as well as generate a unique transaction xAgent running on the Agent Server can exchange the credit 

number (which contains the store number+counter number+ 2 5 information pre-stored in the xAgent and sign the transac- 

transaction number for example) or a unique ID of the point tion - ^ e hotel can issue the electronic room key to the 

of sale terminal (e.g. a phone number) to give to the PEAD xA S ent in the A £ ent Server i usl tne same as lo lhe PEAD - 

user to enter into the PEAD (for example the web phone). When the end user arnves at lne hotel > he can dial tne A S ent 

The user can use the keypad on the PEAD to enter the unique Server number to rec l uest to activate the electronic room key 

ID of the point of sale terminal or use an alternative input stored in the ^gent to open the door through the Internet, 

device built into the PEAD such as a barcode scanner or Similarly, all other applications that can be conducted 

OCR reader to scan in the unique ID of the point of sale through a Web phone, can also be conducted by the ordinary 

terminal. It is also possible lo enter the merchandise bar code cellular phone plus the remote running xAgent in the Agent 

number to the PEAD through the keypad or scanner on the Server. 

PEAD and generate transaction information from the PEAD 35 Tne man y features and advantages of the present inven- 

rather than generate the transaction information from the tion are apparent from the written description, and thus, it is 

point of sale terminal. Then the PEAD can use this unique intended by the appended claims to cover all such features 

transaction number or a unique ID of the point of sale and advantages of the invention. Further, since numerous 

terminal to establish the communication link with the Point- modifications and changes will readily occur to those skilled 

of-Sale system through the wireless network and Internet to 40 in lhe arl ' il is not desirecl to "'mil lhe invention to the exact 

conduct the transaction. Or, the user can give the Point-of- construction and operation as illustrated and described. 

Sale counter the unique PEAD ID (e.g. a cellular phone Hence, all suitable modifications and equivalents may be 

number) to enter into the Point-of-Sale terminal or the resorted to as falling within the scope of the invention. 

Merchant can use the scanner (e.g. barcode scanner or OCR What is claimed is: 

scanner) to scan in the PEAD ID that is attached on the 45 1 A method for approving a transaction request between 

external case of the PEAD in barcode and/or human read- a " electronic transaction system and a portable electronic 

able format to establish the communication link with the authorization device carried by a user using an electronic 

PEAD through the Internet and wireless network to conduct service authorization token, comprising steps of: 

the transaction. This identification process (or link-up receiving at the portable electronic authorization device 

process) can be automated through local wireless port for 50 fi rsl digital data representing the transaction request; 

example: the infrared port or a Bluetooth (short range providing information to the user regarding an ability to 

wireless RF) port. Alternately, the PEAD can be equipped approve the transaction request; and 

with a GPS system, then the PEAD can search automatically when the transaction request is approved by the user, 

the closest Point-of-Sale terminal according to GPS geom- receiving at the portable electronic authorization device 

etry position and establish the link automatically by using a 55 second digital data representing the electronic service 

Location-ID mapping table that maps the proximity of the authorization token. 

point of sale terminal location to the unique ID of the point 2. The method of claim 1, wherein the electronic service 

of sale terminal. Once the link between the PEAD and authorization token can be one of the following: an elec- 

Point-of-Sale terminal is established, the PEAD can display . tronic hotel room key, an electronic airline ticket, an elec- 

the transaction information including the price, items, etc., 60 tronic theater ticket, an electronic car key, and an electronic 

and if the user agrees to pay, he will press the approve button coupon. 

to authorize the transaction. The user approval process and 3. The method of claim 1, wherein the electronic service 

transaction process using the PEAD is also described in U.S. authorization token can be encrypted by the to ken issuer's 

Ser. No. 09/067,176 and U.S. Sen No. 08/759,555, now U.S. private key. 

Pat. No. 5,917,913. 65 4, The method of claim 3, wherein the token issuer can be 

In an aspect of the invention, if the Point-of-Sale terminal one of the following: a hotel, an airline, a movie theater, a 

also has short range wireless communication capability such supermarket, a car rental service and a merchant. 
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5. The method of claim 1, wherein the receiving at the 
portable electronic authorization device second digital data 
representing the electronic service authorization token is 
performed via a wireless communication port associated 
with the portable electronic authorization device. 5 

6. A portable electronic authorization device for approv- 
ing a transaction request with an electronic transaction 
system, using an electronic service authorization token, 
comprising: 

a receiver in the portable electronic authorization device 1Q 
configured to receive first digital data representing the 
transaction request; 

a display configured to provide information to the user 
regarding an ability to approve the transaction request; 
and 1S 

wherein the receiver is further configured such that when 
the transaction request is approved by the user, the 
receiver is configured to receive second digital data 
representing the electronic service authorization token. 

7. The portable electronic authorization device of claim 6, 1Q 
wherein the electronic service authorization token can be 
one of the following: an electronic hotel room key, an 
electronic airline ticket, an electronic theater ticket, an 
electronic car key, and an electronic coupon. 

8. The portable electronic authorization device of claim 6, ?5 
wherein the electronic service authorization token can be 
encrypted by the token issuer's private key. 

9. The portable electronic authorization device of claim 8, 
wherein the token issuer can be one of the following: a hotel, 

an airline, a movie theater, a supermarket, a car rental , 0 
service and a merchant. 

10. The portable electronic authorization device of claim 
6, wherein the receiver is a wireless receiver. 

11. The portable electronic authorization device of claim 

6, wherein the portable electronic authorization device is a 35 
cellular phone. 

12. The portable electronic authorization device of claim 
6, wherein the portable electronic authorization device Ls a 
two-way pager. 

13. The portable electronic authorization device of claim 40 
6, wherein the portable electronic authorization device is a 
wireless device. 

14. The portable electronic authorization device of claim 
6, wherein the electronic transaction system is a service 
reservation system. 45 

15. The portable electronic authorization device of claim 
6, wherein the electronic transaction system is a point of sale 
system. 

16. The portable electronic authorization device of claim 

6, wherein the electronic transaction system is a ticket 50 
reservation system. 

17. The portable electronic authorization device of claim 
6, wherein the portable electronic authorization device is an 
Internet enabled cellular phone. 

18. A method for rendering a service between an elec- 55 
tronic transaction system and portable electronic authoriza- 
tion device carried by a user using an electronic service 
authorization token, comprising steps of: 

transmitting at the portable electronic authorization 
device to the electronic transaction system first digital 60 
data representing the service authorization token; 

validating at the electronic transaction system the first 
digital data representing the service authorization 
token; and 

authorizing the service at the electronic transaction sys- 65 
tern if the first digital data representing the service 
authorization token is valid. 



19. The method of claim 18, wherein the electronic 
service authorization token can be one of the followings: an 
electronic hotel room key, an electronic airline ticket, an 
electronic theater ticket, an electronic coupon. 

20. The method of claim 18, wherein the electronic 
service authorization token can be encrypted by the token 
issuer's private key. 

21. The method of claim 18, wherein the validating step 
includes decrypting the first digital data representing the 
service authorization token using token issuer's public key. 

22. The method of claim 20, wherein the token issuer can 
be one of the followings: a hotel, an airline, a movie theater, 
a supermarket, a merchant. 

23. The method of claim 18, wherein the transmitting the 
electronic service authorization token is performed via a 
wireless communication port associated with the portable 
electronic authorization device. 

24. The method of claim 18, wherein the authorizing step 
includes one of the the services: opening the hotel room, 
admittance of theater, boarding the airplane, discounting the 
transaction amount, igniting a car. 

25. A method for approving a transaction request between 
an electronic transaction system and portable electronic 
authorization device carried by a user using an electronic 
service authorization token via a remote agent server, com- 
prising steps of: 

receiving at the remote agent server first digital data 
representing the transaction request; 

providing information at the remote agent server via the 
portable electronic authorization device to user regard- 
ing an ability to approve the transaction request; and 

when the transaction request is approved by the user, 
receiving at the remote agent server second digital data 
representing the electronic service authorization token. 

26. The method of claim 25, wherein the electronic 
service authorization token can be one of the following: 

an electronic hotel room key, an electronic airline ticket, 
an electronic theater ticket, an electronic car key, an 
electronic coupon. 

27. The method of claim 25, wherein the electronic 
service authorization token can be encrypted by the token 
issuer's private key. 

28. The method of claim 27, wherein the token issuer can 
be one of the followings: a hotel, an airline, a movie theater, 
a supermarket, a car rental service, a merchant. 

29. The method of claim 25, wherein the receiving at the 
remote agent server second digital data representing the 
electronic service authorization token is performed via Inter- 
net. 

30. The method of claim 25, wherein the providing 
information at the remote agent server via the portable 
electronic authorization device step includes converting the 
first digital data representing the transaction request to a 
audio format. 

31. The method of claim 25, wherein the portable elec- 
tronic authorization device is a cellular phone. 

32. The method of claim 25, wherein the transaction 
request approval by the user step includes entering a pass- 
word to the remote agent server via the portable electronic 
authorization device. 

33. A portable electronic authorization device for approv- 
ing a transaction request with an electronic transaction 
system, using an electronic service authorization token via a 
remote agent server, comprising: 

an Internet connection at the remote agent server config- 
ured to receive first digital data representing the trans- 
action request; 
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a receiver in the portable electronic authorization device 
configured to receive from the remote agent server and 
to provide to the user information regarding an ability 
to approve a transaction request; and 

wherein the Internet connection is further configured such 
that when the transaction request is approved by the 
user, the Internet connection is configured to receive 
second digital data representing the electronic service 
authorization token. 

34. The portable electronic authorization device of claim 
33, wherein the electronic service authorization token can be 
one of the following: an electronic hotel room key, an 
electronic airline ticket, an electronic theater ticket, an 
electronic car key, and an electronic coupon. 

35. The portable electronic authorization device of claim 
33, wherein the electronic service authorization token can be 
encrypted by the token issuer's private key. 

36. The portable electronic authorization device of claim 
35, wherein the token issuer can be one of the following: a 
hotel, an airline, a movie theater, a supermarket, a car rental 
service and a merchant. 

37. The portable electronic authorization device of claim 
33, wherein the receiver is a wireless receiver. 

38. The portable electronic authorization device of claim 
33, wherein the portable electronic authorization device is a 
cellular phone. 

39. The portable electronic authorization device of claim 
33, wherein the portable electronic authorization device is a 
two-way pager. 

40. The portable electronic authorization device of claim 
33, wherein the portable electronic authorization device is a 
wireless device. 

41. The portable electronic authorization device of claim 
33, wherein the electronic transaction system is a service 
reservation system. 

42. The portable electronic authorization device of claim 
33, wherein the electronic transaction system is a point of 
sale system. 

43. The portable electronic authorization device of claim 
33, wherein the electronic transaction system is a ticket 
reservation system. 

44. The portable electronic authorization device of claim 
33, wherein the portable electronic authorization device is an 
Internet enabled cellular phone. 

45. A method for rendering a service between an elec- 
tronic transaction system and a portable electronic authori- 
zation device carried by a user using an electronic service 
authorization token via a remote agent server, comprising 
steps of: 

activating the remote agent server via the portable elec- 
tronic authorization device; 

transmitting at the remote agent server to the electronic 
transaction system first digital data representing the 
service authorization token; 

validating at the electronic transaction system the first 
digital data representing the service authorization 
token; and 

authorizing the service at the electronic transaction sys- 
tem if the first digital data representing the service 
authorization token is valid. 

46. The method of claim 45, wherein the electronic 
service authorization token can be one of the followings: an 
electronic hotel room key, an electronic airline ticket, an 
electronic theater ticket, an electronic coupon. 

47. The method of claim 45, wherein the electronic 
service authorization token can be encrypted by the token 
issuer's private key. 
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48. The method of claim 45, wherein the activating step 
includes entering password to the remote agent server via 
the portable electronic authorization device. 

49. The method of claim 45, wherein the validating step 
includes decrypting the first digital data representing the 
service authorization token using token issuer's public key. 

50. The method of claim 47, wherein the token issuer can 
be one of the followings: a hotel, an airline, a movie theater, 
a supermarket, a car rental service, a merchant. 

51. The method of claim 45, wherein the transmitting the 
electronic service authorization token is performed via Inter- 
net. 

52. The method of claim 45, wherein the authorizing step 
includes one of the services: opening the hotel room, admit- 
tance of theater, boarding the airplane, discounting the 
transaction amount, igniting a car. 

53. A method for approving a transaction request between 
an electronic point of sale transaction system and a portable 
electronic authorization device carried by a user, comprising 
the steps of: 

receiving at portable electronic authorization device at a 

point of sale location a first digital data representing the 

transaction request; 
providing information to the user regarding an ability to 

approve the transaction request; 
when the transaction request is approved by the user, 

encrypting transaction approval data as second digital 

data representing approval by the user to purchase the 

item at the point of sale location; and 
transmitting the second digital data to the electronic 

transaction system to approve the transaction request 

with the electronic transaction system. 

54. The method of claim 53, wherein the encrypting the 
approval data is performed using a public key cryptography 
technique. 

55. The method of claim 53, wherein the receiving step 
includes establishing the communication link between the 
portable electronic authorization device and the electronic 
point of sale transaction system via the wireless network and 
Internet. 

56. The method of claim 55, wherein the establishing the 
communication link step includes entering the unique ID of 
the electronic point of sale transaction system to the portable 
electronic authorization device. 

57. The method of claim 56, wherein the entering the 
unique ID step includes using the keypad of the portable 
electronic authorization device to enter the unique ID of the 
electronic point of sale transaction system. 

58. The method of claim 56, wherein the entering the 
unique ID step includes using the scanner of the portable 
electronic authorization device to enter the unique ID of the 
electronic point of sale transaction system. 

59. The method of claim 55, wherein the establishing the 
communication link step includes entering the unique ID of 
the portable electronic authorization device to the electronic 
point of sale transaction system. 

60. The method of claim 59, wherein the entering the 
unique IDstep includes using the keypad of the electronic 
point of sale transaction system to enter the unique ID of the 
portable electronic authorization device. 

61. The method of claim 59, wherein the entering the 
unique ID step includes using the scanner of the electronic 
point of sale transaction system to enter the unique ID of the 
portable electronic authorization device. 

62. The method of claim 55, wherein the establishing the 
communication link step includes automatically identifying 
the proximity of the location of the electronic point of sale 
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transaction system by using the GPS of the portable elec- 
tronic authorization device. 

63. The method of claim 59, wherein the unique ID of the 
portable electronic authorization device is a cellular phone 
number. 5 

64. The method of claim 53, wherein the receiving step 
includes establishing the communication link between the 
portable electronic authorization device and the electronic 
point of sale transaction system via infrared. 

65. The method of claim 53, wherein the receiving step 10 
includes establishing the communication link between the 
portable electronic authorization device and the electronic 
point of sale transaction system via short range RF. 

66. A portable electronic authorization device for approv- 
ing a transaction request with an electronic point of sale 15 
transaction system, comprising: 

a receiver in the portable electronic authorization device 
configured to receive first digital data representing the 
transaction request; 

a display configured to provide information to the user "° 
regarding an ability to approve the transaction request; 

when the transaction request is approved by the user, the 
portable electronic authorization device is configured 
to encrypt the transaction approval data as second ^. 
digital data representing approval by the user to pur- 
chase the item at the point of sale location; and 

a transmitter configured to transmit the second digital data 
to the electronic transaction system to approve the 
transaction request with the electronic transaction sys- 33 
tern. 

67. A method for approving a transaction request between 
an electronic point of sale transaction system and a portable 
electronic authorization device carried by a user via a remote 
agent server, comprising the steps of: 35 

receiving at the remote agent server at a point of sale 
location a lirst digital data representing the transaction 
request; 

providing information at the remote agent server via the 
portable electronic authorization device to user regard- 40 
ing an ability to approve the transaction request; 

when the transaction request is approved by the user via 
the portable electronic authorization device, encrypting 
transaction approval data at the remote agent server as 
second digital data representing approval by the user to 45 
purchase the item at the point of sale location; and 

transmitting the second digital data at the remote agent 
server to the electronic transaction system to approve 
the transaction request with the electronic transaction 5Q 
system. 

68. The method of claim 67, wherein the encrypting the 
approval data is performed using a public key cryptography 
technique. 



69. The method of claim 67, wherein the receiving step 
includes establishing the communication link between the 
portable electronic authorization device and the electronic 
point of sale transaction system via the wireless network and 
Internet. 

70. The method of claim 69, wherein the establishing the 
communication link step includes entering the unique ID of 
the electronic point of sale transaction system to the portable 
electronic authorization device. 

71. The method of claim 70, wherein the entering the 
unique ID step includes using the keypad of the portable 
electronic authorization device to enter the unique ID of the 
electronic point of sale transaction system. 

72. The method of claim 69, wherein the establishing the 
communication link step includes entering the unique ID of 
the portable electronic authorization device to the electronic 
point of sale transaction system. 

73. The method of claim 72, wherein the entering the 
unique ID step includes using the keypad of the electronic 
point of sale transaction system to enter the unique ID of the 
portable electronic authorization device. 

74. The method of claim 72, wherein the entering the 
unique ID step includes using the scanner of the electronic 
point of sale transaction system to enter the unique ID of the 
portable electronic authorization device. 

75. The method of claim 72, wherein the unique ID of the 
portable electronic authorization device is a cellular phone 
number. 

76. A portable electronic authorization device for approv- 
ing a transaction request with an electronic point of sale 
transaction system, using a remote agent server, comprising: 

an internet connection at the remote agent server config- 
ured to receive first digital data representing the trans- 
action request; 

a receiver in the portable electronic authorization device 
configured to receive from the remote agent server and 
to provide to the user information regarding an ability 
to approve a transaction request; and 

when the transaction request is approved by the user via 
the portable electronic authorization device, the remote 
agent server is configured to encrypt the transaction 
approval data as second digital data representing 
approval by the user to purchase the item at the point 
of sale location; and 

wherein the Internet connection is further configured to 
transmit the second digital data at the remote agent 
server to the electronic transaction system to approve 
the transaction request with the electronic transaction 
system. 
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